home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
dhc
/
dhc-minutes-90june.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
7KB
|
154 lines
CURRENT MEETING REPORT (June 8, 1990)
Reported by Ralph Droms/ Bucknell University
Introduction
------------
John Veizades, Jeff Mogul, Greg Minshall, Bob Morgan, Leo McLaughlin
and Ralph Droms attended a ``mid-term'' meeting of the Dynamic Host
Configuration working group. Jeff Mogul was kind enough to host the
meeting at DEC's Western Research Lab. The purpose of the meeting was
to discuss the mechanism for network address allocation proposed at
the Pittsburgh IETF plenary. The participants were chosen to
represent the two mechanisms as presented at the Pittsburgh meeting.
The time and location were chosen for the convenience of the
participants.
The allocation mechanism under discussion at this meeting describes
the way in which DHC servers allocate and transmit network addresses
to DHC clients. This new mechanism was first proposed by Leo and Jeff
at the Pittsburgh meeting. In this mechanism, the DHC servers
allocate and return a single network address to a requesting client.
Discussion
----------
The DHC WG generally agrees that the new DHC protocol should be based
on the existing BOOTP protocol. The primary motivations behind this
decision are the desire to capture BOOTP forwarding agent code in
existing routers and the desire to avoid inventing a new protocol when
an existing protocol can be used.
The WG further agrees that the new protocol should be first defined to
carry network layer configuration parameters to the client: network
address, subnet mask, broadcast address and local network MTU. The
question arises: how shall the DHC server select a network address to
return to the client? There are several points on which one can
compare the two network address allocation mechanisms discussed in the
introduction:
o Relative complexity of client and server code
o Accuracy/correctness of allocated addresses
o Compatibility with existing BOOTP clients
o Ability to maintain coherent distributed information about
allocated addresses
The explicit allocation mechanism has appeal because it captures
existing BOOTP clients and because it can make the client code much
simpler. However, at the Pittsburgh meeting there was much discussion
about whether the central allocation mechanism could be made to work;
would it be too complex and would it be possible to maintain the
global database required for distributed allocation of addresses?
1
New Mechanism
--------------
At the June meeting, we developed an outline of the specific address
mechanism, which we present for comment here. From the client's point
of view, the new DHC protocol works the same as the existing BOOTP
mechanism. In fact, we expect existing BOOTP clients to interoperate
with DHC servers without requiring any change to initialization
software. There are some new, optional transactions that optimize the
interaction between DHC clients and servers:
o Client sends DHC request for network parameters
o Server sends response with network parameters and explicit network
address (Note: This assumes the client receives at least one
reply. If no replies arrive, the client may, at the discretion of
local administration, enter ``genesis state'' [see below for
details].)
o (Opt.) Client updates local network ARP caches with an ARP
broadcast reply
o (Opt.) Client releases unused addresses from duplicate server
responses
o (Opt.) Client releases selected address during orderly close
Problem Areas with Explicit Allocation
--------------------------------------
The first problem area encountered by a server when explicitly
allocating a specific network address rather than a range of addresses
is determining which addresses are already in use and which may be
allocated or reallocated. Because the server may not be on the same
subnet as the client, the server must use an ICMP echo message to
probe for hosts already using a specific address. Thus all
participants using network addresses in the dynamic allocation range
(whether statically or dynamically allocated) must implement ICMP echo
message processing.
Some hosts, while implementing ICMP echo processing, may go into a
state where ICMP echo requests are ignored for extended periods. The
client request protocol includes two new extensions to help the server
handle such clients:
o ``brain damage'' - indicating that the client may ignore ICMP
requests
o ``reserve forever'' - requesting permanent allocation of a network
address
To meet the goal of reissuing the same network address to a host
whenever possible, while allowing more hosts on a subnet than
addresses available for allocation (obviously, not all hosts can be
active simultaneously), the server must be able to timeout the
allocation of an address to a host, and reuse addresses in LRU order.
The optional
2
``release address'' message from the client to the server also helps
the server determine when a network address may be reallocated
The second problem area, which was discussed at some length in
Pittsburgh, is the mechanism through which multiple servers can
coordinate the allocation of addresses. We believe this is not a
difficult problem. First, note that the problem only arises when
multiple servers share responsibility for allocation of addresses on a
single subnet. Second, the servers need not interact dynamically,
after every network address is allocated. Rather, the address space
for the target subnet can be partitioned among the servers, which each
only allocate addresses from its own partition. Periodically, the
servers exchange allocation information, possibly repartitioning the
currently unallocated addresses to reflect client request load.
Genesis State
--------------
In the absence of any servers, clients may choose to enter ``genesis
state''. This state is intended for use in small networks in which
resources for support of DHC servers may not be available (the
``dentist's office'' network). In genesis state, the client picks an
IP address, probes for any current use of that address and then
defends the selected address using ARP. The genesis state mechanism
looks much like the Athena NIP address allocation mechanism.
Conclusion
----------
The problem areas in a protocol where network addresses are explicitly
selected by a possibly remote server seem to be identifiable and can
be surmounted by careful design of the protocol and server behavior.
The advantages of explicit network address allocation appear to
outweigh the disadvantages, and I recommend the DHC WG further
investigate the new address allocation mechanism.
3